Control MQTT en vivo

tip

El control de MQTT en vivo está destinado para el control en tiempo real. Para enviar horarios por adelantado, consulte Control Programado de MQTT en su lugar.

Esta guía te ayudará a configurar MQTT en tu SmartgridOne Controller para controlar y monitorear de forma remota instalaciones de baterías y paneles solares.

Lo que necesitas

1. SmartgridOne Controller con conexión a internet.
2. Credenciales de MQTT: Esto se puede solicitar enviando un correo electrónico a support@eniris.be.
3. Entorno de desarrollo de Python (o cualquier otro cliente MQTT). Esta guía utiliza un ejemplo básico escrito en Python para que empieces con MQTT y el envío de comandos. Recomendamos usar Python por su facilidad de uso, pero se admite cualquier otro cliente MQTT.

Información adicional

MQTT es un protocolo de comunicación rápido a través de internet. Es un sistema de mensajes de publicar/suscribir, que permite una conexión directa entre tu máquina y el SmartgridOne Controller. Tus activos están clasificados en grupos de solar, batería, vehículos eléctricos (EV) y HVAC.

Configuración inicial (Punto de partida para nuevos usuarios)

Tengo un SmartgridOne Controller que me gustaría configurar para Control Remoto MQTT.

1. Verifica tu red

Asegúrate de que tu red permita el tráfico de red mqtt a través del puerto 1883. Puedes hacerlo usando el comando:

nc -zv mqtt.eniris.be 1883

Cuando este comando no está disponible, puedes descargar y ejecutar este código en python como alternativa.

Cuando tengas dudas, consulta a tu ingeniero de red o utiliza temporalmente el hotspot 4G/5G de tu teléfono cuando ocurran errores de conexión.

nota

Cuando el puerto 1883 no es accesible desde tu red, ofrecemos una alternativa en el puerto 80. Esto se puede configurar en tu cliente MQTT en un paso posterior de este manual.

2. Agrega tus dispositivos

Inicia sesión en la interfaz de puesta en marcha y asegúrate de que los dispositivos estén añadidos a la SmartgridOne Controller.

3. Agrega la señal externa de MQTT

4. Habilita la señal remota de MQTT

El campo 'VPP ID' debe dejarse vacío.

El tiempo de espera del mecanismo de respaldo le indica al SmartgridOne Controller cuánto tiempo debe esperar por nuevos comandos. Cuando el SmartgridOne Controller deja de recibir comandos, automáticamente adopta la estrategia predeterminada después de este tiempo de espera.

Luego, selecciona todos los dispositivos que deseas incluir en el Control Remoto de MQTT.

5. Se ha agregado la señal remota

La interfaz de Control Remoto de MQTT ha sido activada en el SmartgridOne Controller.

Ahora estamos listos para enviar algunos comandos básicos utilizando un ejemplo simple. La columna de Estado te indica si algún comando está activo.

Script de demostración en Python

Un buen punto de partida sería probar tu nueva integración configurada con un ejemplo simple.

Este código de prueba hace un trabajo simple de enviar continuamente los siguientes comandos:

• Batería: Cargar a 5 kW
• Solar: Establecer potencia a 0 kW

El SmartgridOne Controller responde continuamente con un mensaje de 'retroalimentación' que contiene los valores de potencia de la red y de los activos observados. Esta función también está incluida en este ejemplo.

Descarga el archivo a continuación en tu IDE de Python preferido. Completa tu número de serie y credenciales de MQTT y ejecuta el script:

Cuando lo anterior sea exitoso, puedes continuar enviando otros tipos de comandos. Todos los comandos están descritos en nuestra Documentación de Control Remoto MQTT.

Documentación de MQTT para Envío de Comandos

Esta sección detalla el formato de mensajería MQTT y los requisitos de carga útil para controlar de forma remota las políticas de potencia en dispositivos dentro de la red del SmartgridOne Controller.

Tema de MQTT

El tema de MQTT utilizado para enviar comandos está estructurado de la siguiente manera:

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Donde 'controller SN' debe ser reemplazado por el número de serie real del SmartgridOne Controller que deseas controlar.

Estructura de la Carga Útil de MQTT

Los comandos se envían como cargas útiles JSON. La estructura de la carga útil está diseñada para especificar varias políticas de gestión de energía y puntos de ajuste para diferentes componentes del sistema de red inteligente. Aquí está el esquema de la carga útil con descripciones detalladas de los campos:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "<Policy Type>",
        "<Component Power Setpoint>": <Setpoint in watts>
    }
}

Descripción de Campos

tip

Se pueden controlar múltiples tipos de dispositivos (p. ej., baterías + solar) al mismo tiempo.

• extraTags (Objeto):
  • nodeId (Cadena): Un identificador único para el nodo dentro de la red del SmartgridOne Controller. Esto es igual a tu número de serie, seguido de '_site_0' para la mayoría de los dispositivos SmartgridOne Controller.
• time (Entero): Marca de tiempo Unix en segundos que indica el momento en que se envía el mensaje.
• fields (Objeto):
  • <Component>_policy (Cadena): Tipo de política para el componente. Es opcional y si no se especifica, el sistema volverá a la configuración predeterminada del SmartgridOne Controller.
  • <Component>_power_setpoint_w (Flotante): Punto de ajuste de potencia deseado en vatios para el componente. Esto es opcional y solo relevante si se especifica una política correspondiente.

Componentes y Políticas

info

Los activos del mismo tipo (p. ej., dos baterías) se combinarán como un solo componente. Por ejemplo, cuando se instalan dos baterías de 5 kWh, se tratará como una batería de 10 kWh.

Cada componente en el objeto fields puede incluir una política y un punto de ajuste de potencia. Se pueden controlar los siguientes componentes:

• solar_policy y solar_power_setpoint_w:

  • Controla la política de generación de energía solar y el punto de ajuste. Políticas admitidas:
    • Política de punto de ajuste: Establece la máxima potencia producida por todas las instalaciones solares conectadas combinadas. El campo solar_power_setpoint_w debe establecerse en el límite de potencia de producción en vatios.
    • Política de restricción de inyección: Produce a plena potencia, siguiendo los límites actuales de la red.
    • Política de costo: Habilita la minimización de costos de precios de día anterior (mercado de EPEX Spot) en la producción solar. Cuando ocurren precios de inyección negativos, restringimos la producción al consumo propio. Cuando tanto el precio de retirada como el de inyección son negativos, apagamos todas las instalaciones solares. Se ignora el campo solar_power_setpoint_w.
    • Política de apagado: Desactiva toda interacción para todos los activos solares. Advertencia: los límites no se protegen en este modo. Se ignora el campo solar_power_setpoint_w.

• storage_policy y storage_power_setpoint_w:

• Controla la política del sistema de almacenamiento de energía y la tasa de descarga o carga de energía.

  • Punto de ajuste de la política: Establece la potencia total de carga (punto de ajuste positivo) o la potencia de descarga (punto de ajuste negativo) para el grupo de baterías. Cuando se conectan múltiples baterías, entonces el punto de ajuste se divide según la potencia de carga/descarga disponible para estresar igualmente las baterías. El campo storage_power_setpoint_w se establece en la potencia deseada de la batería.
  • Costo de la política: Habilita la optimización de costos de precios de día anterior (mercado EPEX Spot) en las baterías, cargándolas en las horas baratas y utilizando la energía en las horas caras. El campo storage_power_setpoint_w se ignora.
  • Política de autoconsumo: Habilita un algoritmo simple de autoconsumo en las baterías. La producción solar excedente se almacena en la batería durante el día, y cuando el sol se pone, se toma energía de la batería. El campo storage_power_setpoint_w se ignora.
  • Política apagada: Desactiva toda interacción para todos los activos de batería. Advertencia: los límites no están siendo controlados en este modo. El campo storage_power_setpoint_w se ignora.

• heat_pump_policy:

  • Activa/desactiva los sistemas de bomba de calor. Los tiempos mínimos y máximos de encendido siempre se respetarán.
  • Costo de la política: Habilita la optimización de costos de precios de día anterior (mercado EPEX Spot) en las bombas de calor. El algoritmo de precios dinámicos local decide los mejores períodos de encendido.
  • Política de autoconsumo: Enciende las bombas de calor si se produce un exceso de energía solar.
  • Política apagada: Apaga las bombas de calor.
  • Política encendida: Enciende las bombas de calor.

• switched_load_policy:

  • Activa/desactiva sistemas controlados por relé. Esto podría ser el relé incorporado o relés conectados a la red.
  • Costo de la política: Habilita la optimización de costos de precios de día anterior (mercado EPEX Spot) en el relé.
  • Política de autoconsumo: Enciende el relé si se produce un exceso de energía solar.
  • Política apagada
  • Política encendida

• variable_power_load_policy y variable_power_load_power_setpoint_w:

  • Gestiona la política de consumo de energía de vehículos eléctricos y el punto de ajuste.
  • Punto de ajuste de la política: Establece la potencia total de carga para el grupo de vehículos eléctricos (EV). El campo variable_power_load_power_setpoint_w se establece en la potencia de carga deseada.
  • Costo de la política: Habilita la optimización de costos de precios de día anterior (mercado EPEX Spot) en las baterías, cargándolas en las horas baratas. El campo variable_power_load_power_setpoint_w se ignora.
  • Política de autoconsumo: Habilita la carga si se produce un exceso de energía solar. El campo variable_power_load_power_setpoint_w se ignora.
  • Política apagada: Desactiva toda interacción para todos los activos de vehículos eléctricos. El campo variable_power_load_power_setpoint_w se ignora.

• site_policy y site_power_setpoint_w:

  • Gestiona los límites de exportación del sitio.
  • Política de exportación: Establece el límite de exportación para el sitio. El campo site_power_setpoint_w se establece en el límite de exportación.
  • Política predeterminada: Restaura el límite del sitio a la potencia de exportación predeterminada, establecida en la configuración del controlador.

Control del Dispositivo

Los dispositivos específicos también pueden ser controlados, en lugar de grupos de dispositivos basados en sus tipos. El mensaje tiene una estructura idéntica:

• nodeId_policy y nodeId_power_setpoint_w

Cuando se envían dos comandos al mismo activo (por ejemplo, un comando específico de dispositivo a un inversor solar y un comando a todos los dispositivos solares), el método de control específico de dispositivo tendrá preferencia sobre el control por tipo de dispositivo.

Comportamiento de reserva

Para cada componente, si no se especifica la _policy y _power_setpoint_w, el sistema utilizará automáticamente la política de reserva configurada en el SmartgridOne Controller. Esto asegura que cada dispositivo o grupo de dispositivos opere de manera segura y continúe funcionando incluso si no se proporcionan instrucciones específicas.

Si no se envía ningún comando en absoluto, después de 60 segundos (o el período de tiempo de espera configurado), se reactivarán las políticas predeterminadas para los activos.

Ejemplo de carga útil

A continuación se muestra un ejemplo de una carga útil para establecer varias políticas y puntos de ajuste:

{
    "extraTags": {
        "nodeId": "OM12404080000000000_site_0"
    },
    "time": 1714652046,
    "fields": {
        "solar_policy": "setpoint",
        "solar_power_setpoint_w": 5000,
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": -5000
    }
}

En este ejemplo, la potencia solar se establece para generar hasta 5000 vatios, y el sistema de almacenamiento de energía se establece para cargar o descargar a una tasa de 5000 vatios, dependiendo del signo del valor del punto de ajuste. Si se omitiera cualquiera de las políticas solar_policy o storage_policy, el dispositivo respectivo revertiría a la configuración predeterminada determinada por el SmartgridOne Controller.

Documentación MQTT para Recibir retroalimentación

Esta sección describe la estructura y contenido de los mensajes de retroalimentación enviados por el SmartgridOne Controller a través de MQTT. Estos mensajes se publican en el tema standard1/outbound/remoteControlMetrics/feedback/<Controller SN> después de que se ha procesado un comando.

Tema de Retroalimentación MQTT

El tema de retroalimentación MQTT está estructurado de la siguiente manera:

standard1/outbound/remoteControlMetrics/feedback/<Controller SN>

Donde <Controller SN> debe ser reemplazado por el número de serie del SmartgridOne Controller que está enviando la retroalimentación.

Estructura de Carga Útil de Retroalimentación MQTT

Todos los activos están agrupados por su tipo. Esto significa que dos instalaciones solares individuales de 3 kW se tratarán como un activo de 6 kW.

Los mensajes de retroalimentación están formateados como cargas útiles JSON. Estas cargas útiles proporcionan retroalimentación detallada sobre el estado del sistema después de aplicar los comandos de punto de ajuste, considerando los límites de la red/dispositivo. A continuación se presenta la estructura de la carga útil de retroalimentación con descripciones de sus campos:

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Grid Active Power in Watts>,
                "today_imported_energy_Wh": <Grid Imported Energy in Watt-hours>,
                "today_exported_energy_Wh": <Grid Exported Energy in Watt-hours>,
                "import_limit_W": <Grid Import Limit in Watts>,
                "export_limit_W": <Grid Export Limit in Watts>,
            },
            "vpp_id": "<Virtual Power Plant Identifier>",
            "storage": {
                "energy_stored_Wh": <Energy Stored in Watt-hours>,
                "energy_capacity_Wh": <Total Energy Capacity in Watt-hours>,
                "mean_soc_perc": <Mean State of Charge Percentage>,
                "active_power_W": <Active Power in Watts>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "executed_policy": <Policy Executed by the Controller>,
                "max_charge_power_W": <Maximum Charge Power in Watts>,
                "max_discharge_power_W": <Maximum Discharge Power in Watts>,
                "today_charged_Wh": <Energy Charged on the Current Today in Watt-hours>,
                "today_discharged_Wh": <Energy Discharged on the Current Today in Watt-hours>,
                "nr_devices": <Number of Controlled Storage Devices Installed>
            },
            "solar": {
                "active_power_W": <Solar Active Power in Watts>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "executed_policy": <Policy Executed by the Controller>,
                "capacity_W": <Capacidad solar en vatios>,
                "today_energy_Wh": <Energía producida hoy en vatios-hora>.
                "nr_devices": <Número de dispositivos solares controlados instalados>
            },
            "heat_pump": {
                "executed_policy": <Política ejecutada por el controlador>,
                "operation_modes": <Modos de operación de la bomba de calor>,
                "executed_power_W": <Punto de potencia establecido enviado a los dispositivos en vatios>,
                "nr_devices": <Número de dispositivos de bomba de calor controlados instalados>
            },
            "switched_load": {
                "executed_policy": <Política ejecutada por el controlador>,
                "devices_on": <Número de dispositivos encendidos>,
                "devices_off": <Número de dispositivos apagados>,
                "executed_power_W": <Punto de potencia establecido enviado a los dispositivos en vatios>,
                "nr_devices": <Número de dispositivos de carga conmutada controlados instalados>  
            }
        },
        "response_code": <Código de respuesta>
    },
    "fields": {},
    "requestTime": "<Marca de tiempo Unix>",
    "time": "<Marca de tiempo Unix>",
    "siteNodeId": "<SN del controlador>_sitio_0"
}

### Descripción de los campos
- time (Entero): Marca de tiempo Unix que indica el momento en que se envió el mensaje de retroalimentación.
- fields (Objeto):
    - state (Objeto):
        - vpp_id (Cadena): Identificador para la Planta de Energía Virtual asociada con este dispositivo.
        - grid (Objeto):
            - active_power_W (Flotante): Representa la potencia activa actual en la red en vatios.
            - today_imported_energy_Wh (Flotante): La energía total tomada de la red hoy en vatios-hora. Nota: Hoy se da en horario UTC.
            - today_exported_energy_Wh (Flotante): La energía total inyectada de nuevo en la red hoy en vatios-hora. Nota: Hoy se da en horario UTC.
            - import_limit_W (Flotante): El límite de importación de la red en vatios,
            - export_limit_W (Flotante): El límite de exportación de la red en vatios,
        - storage (Objeto):
            - energy_stored_Wh (Flotante): Cantidad actual de energía almacenada en vatios-hora.
            - energy_capacity_Wh (Flotante): Capacidad total de energía del sistema de almacenamiento en vatios-hora.
            - mean_soc_perc (Flotante): Estado de carga como porcentaje. Este es el promedio ponderado entre todas las baterías conectadas. (cuando múltiples baterías están conectadas: por ejemplo, la batería 'a' tiene una capacidad de energía de 10 kWh y un estado de carga del 20%; la batería 'b' tiene una capacidad de energía de 20 kWh y un estado de carga del 50%, entonces el mean_soc_perc es del 40%)
            - active_power_W (Flotante): Potencia activa actual para el sistema de almacenamiento en vatios, mostrando la tasa de carga o descarga.
            - max_charge_power_W (Flotante): Potencia máxima a la que se puede cargar el almacenamiento.
            - max_discharge_power_W (Flotante): Potencia máxima a la que se puede descargar el almacenamiento.
            - executed_power_W (Flotante): La suma de la potencia total solicitada para (cargar) o descargar de los activos de almacenamiento, enviada por nuestro algoritmo de control. Solo aplicable si la política 'follow_setpoint' está activa.
            - executed_policy (Cadena): Las políticas que se han aplicado a los controlables.
            - today_charged_Wh (Flotante): La energía total cargada en los activos de batería controlables hoy. Nota: Hoy se da en horario UTC.
            - today_discharged_Wh (Flotante): La energía total descargada de los activos de batería controlables hoy. Nota: Hoy se da en horario UTC.
            - nr_devices (Entero): El número de activos de batería controlables.
        - solar (Objeto):
            - active_power_W (Flotante): Potencia activa actual generada por los paneles solares en vatios.
            - capacity_W (Flotante): Capacidad total del sistema de generación solar en vatios.
            - executed_power_W (Flotante): La suma de la potencia total solicitada de los activos solares, enviada por nuestro algoritmo de control. Solo aplicable si la política 'follow_setpoint' está activa.
            - executed_policy (Cadena): Las políticas que se han aplicado a los controlables.
            - today_energy_Wh (Flotante): La energía total producida de los activos solares controlables hoy. Nota: Hoy se da en horario UTC.
            - nr_devices (Entero): El número de activos solares controlables.
        - heat_pump (Objeto):
            - executed_policy (Cadena): Las políticas que se han aplicado a los controlables.
            - operation_modes (Cadena): El modo de la bomba de calor (Modo de bloqueo, Modo de aumento, Modo de auto control)
            - executed_power_W (Flotante): La potencia esperada que está utilizando actualmente.
            - nr_devices (Entero): El número de bombas de calor controlables.
        - switched_load (Objeto):
            - executed_policy (Cadena): Las políticas que se han aplicado a los controlables.
            - devices_on (Entero): El número de dispositivos encendidos.
            - devices_off (Entero): El número de dispositivos apagados.
            - executed_power_W (Flotante): La potencia que está utilizando actualmente (si está disponible).
            - nr_devices (Entero): El número de cargas conmutadas controlables de encendido/apagado.
        - nodeId (Objeto):
            - Si se incluye un nodeId en el comando, la retroalimentación contendrá el estado correspondiente del dispositivo.
    - response_code (Entero):
        - Indica el estado de la operación. Un response_code de 0 suele significar éxito, mientras que otros valores pueden indicar diferentes tipos de errores o información de estado (estos deben detallar en una referencia separada).

### Ejemplo de carga útil de retroalimentación
Aquí hay un ejemplo de un mensaje de retroalimentación después de un comando para establecer varios puntos de ajuste de potencia:

<ClickableImage src="/img/generic/mqtt-example-feedback.png" alt="Imagen 1" maxWidth="450px" />

Esta retroalimentación demuestra el estado operativo actual del sistema tras la ejecución de los puntos de ajuste, indicando los efectos en la generación solar, el almacenamiento y la interacción general con la red.

## Versiones de MQTT soportadas y comportamiento en temas no autorizados
Al usar MQTT, es importante considerar las diferencias en las especificaciones entre las versiones 3.1, 3.1.1 y 5.0, particularmente en relación con el comportamiento del broker cuando los clientes publican en temas no autorizados.

Según la especificación MQTT 3.1.1 (ver OASIS MQTT 3.1.1 Specification, sección MQTT-3.3.5-2), un broker debe terminar la conexión tan pronto como un cliente envía un PUBLISH a un tema para el cual no tiene permiso. Este comportamiento puede llevar a desconexiones inesperadas para los clientes que intentan publicar en temas mal configurados o no autorizados.

En MQTT 3.1, este requisito no está presente. Cuando un cliente publica en un tema no autorizado bajo esta versión, el broker típicamente ignora el mensaje (caída silenciosa) sin terminar la conexión. Esto hace que MQTT 3.1 en algunos casos sea más adecuado cuando la robustez contra errores de configuración o permisos temporales faltantes es más importante que la aplicación estricta de la seguridad.

Aunque MQTT 5.0 introduce la capacidad de trabajar con códigos de razón (como PUBACK con un motivo de rechazo), esto requiere soporte tanto en el lado del cliente como en el del servidor. Por lo tanto, migrar a MQTT 5.0 implica un esfuerzo adicional de implementación.

__Consecuencias de ignorar la compatibilidad:__
Si un cliente se conecta utilizando MQTT 3.1.1 y intenta publicar mensajes en temas no autorizados, el intermediario terminará abruptamente la sesión. Esto puede llevar a inestabilidad, pérdida de conectividad o aumento de carga debido a intentos de reconexión repetidos.

__Enfoque recomendado:__
Para sistemas donde los clientes pueden (temporalmente) intentar publicar en temas no autorizados, o donde el manejo de errores no se implementa de manera estricta, recomendamos utilizar MQTT 3.1. Esto asegura conexiones más estables y evita desconexiones no intencionadas durante el tiempo de ejecución.